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DETAILED ACTION 

1 . Claims 1-23 were presented for examination. The priority date established for 
examination of this application is 6/5/2000. Claims 1-23 remain pending in this 
application and were considered by the examiner. 

Priority 

2. Applicant's claim for domestic priority under 35 U.S.C. 1 19(e) is acknowledged. 

Drawings 

3. The drawings are objected to as failing to comply with 37 CFR 1 .84(p)(5) 
because they do not include the following reference sign(s) mentioned in the 
description: an end 220 (Pg. 10, par. 0030, I. 3), forks 260 and states 270 (Pg. 10, par. 
0030, 1. 5). Corrected drawing sheets in compliance with 37 CFR 1 .121(d) are required 
in reply to the Office action to avoid abandonment of the application. Any amended 
replacement drawing sheet should include all of the figures appearing on the immediate 
prior version of the sheet, even if only one figure is being amended. The replacement 
sheet(s) should be labeled "Replacement Sheet" in the page header (as per 37 CFR 

1 .84(c)) so as not to obstruct any portion of the drawing figures. If the changes are not 
accepted by the examiner, the applicant will be notified and informed of any required 
corrective action in the next Office action. The objection to the drawings will not be held 
in abeyance. 

Specification 

4. The disclosure is objected to because of the following informalities: "a variety 
types" (e.g., Pg. 3, par. 0005, 1. 6), "steps in well coherent and logical to retrieve" (Pg. 
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14, par. 00039, 1. 6) and "allowing the end-user directly interacts with and manipulates" 
(Pg. 15, par. 00041, 1. 5) are examples of improperly constructed phrases found in the 
specification. These examples are representative of and do not comprise all such 
errors noted in the specification. Applicant is requested to review and appropriately 
correct all errors in the specification. 

5. The use of the trademarks "Java" (e.g., Pg. 6, Par. 00018, 1. 4), "CORBA" (e.g., 
Pg. 11, Par. 00031, 1. 12), "DCOM" (e.g., Pg. 11, Par. 00031, 1. 12), "Internet Explorer 
(e.g., Pg. 12, Par. 00035, I. 5), and "Netscape" (e.g., Pg. 12, Par. 00035, 1. 6) have been 
noted in this application. They should be capitalized wherever they appear and be 
accompanied by the generic terminology. 

Although the use of trademarks is permissible in patent applications, the 
proprietary nature of the marks should be respected and every effort made to prevent 
their use in any manner which might adversely affect their validity as trademarks. 

To expedite correction on this matter, the examiner suggests the following 
guidelines for applicant to follow in amending the specification: 

i. Capitalize each letter of a trademark or accompany the trademark with an 
appropriate designation symbol, e.g., ™ or ®, as appropriate. 

ii. Use each trademark as an adjective modifying a descriptive noun. For 
example, it would be appropriate to recite "the JAVA platform" or "the JAVA 
programming language". Note that in these examples, "platform" and "programming 
language" provide accompanying generic terminology, describing the context in which 
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the trademark is used. By itself, the trademark JAVA specifies only the source of the 
so-labeled products, namely SUN Microsystems, Inc. 

Claim Objections 

6. Claims 7, 13, and 22 are objected to because of the following informalities: 
"high-level structure" should be pluralized for conformance with applicant's previous 
pluralizations, e.g. "defining one or more interrelated objects ... and constructing one or 
more high-level structure Appropriate correction is required. 

Claim Rejections - 35 USC §112 

7. The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification shall conclude with one or rtiore claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

8. Claims 1-2, 4-8, 17-18, and 20-23 are rejected under 35 U.S.C. 1 12, second 
paragraph, as being indefinite for failing to particularly point out and distinctly claim the 
subject matter which applicant regards as the invention. 

Claims 1 and 17 recite the limitation "the converted response objects" in the last 
sentence of each claim, respectively. There is insufficient antecedent basis for this 
limitation in these claims. 

Claims 2, 4-8, 18, and 20-23 are also rejected for being dependent on a rejected 
base claiim. ' 

Claims 3 and 19 incorporate a limitation into their rejected base claims which 
corrects the deficiency inherent in those claims, and as such are not rejected under 35 
U.S.C. 1 12, second paragraph. Applicant is suggested to incorporate this limitation into 
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the respective rejected base claims of claims 3 and 19 to overcome the rejection under 
35 U.S.C. 112, second paragraph, as applicant has done in claim 9. 

Claim Rejections - 35 CISC § 103 

9. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1 , 148 
USPQ 459 (1966), that are applied for establishing a background for determining 
obviousness under 35 U.S.C. 103(a) are summarized as follows: 

1 . Determining the scope and contents of the prior art. 

2. Ascertaining the differences between the prior art and the claims at issue. 

3. Resolving the level of ordinary skill in the pertinent art. 

4. Considering objective evidence present in the application indicating 
obviousness or nonobviousness. 

10. Claims 1-7, 9-15, and 17-22 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Iyengar et al. (6,018,627) in view of Diec (6,324,568). 

Referring to claim 1 , Iyengar et al. ('627) disclose a system for application 
building in an object-oriented environment {developing software applications at an 
abstract design level), in which the user may create business process models and 
assign business logic to those models, and then package and deploy the created 
application (See Abstract, Figs. 1-14 and related text). The method of Iyengar et al. 
('627) comprises: 
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"capturing an application logic at the abstract design level as ... visual models . . . 
independent from an underlying programming technology" (E.g., see Figs. 2a-b, 3 and 
4, and Col. 5, 1. 21-30 and 37-59, which states that the preferred embodiment of the 
invention uses UML, "a method for specifying, visualizing , and documenting the 
components (objects) of a system under development", to generate models which can 
be transformed "into any other business process model or object model." The modeling 
system works independently of the tools used to create the application, and 
independently of the middleware (connectivity software) that the application interfaces 
with.) 

"deploying the captured application logic to an execution platform 11 (E.g., see Fig. 
1 - Deploy Application 32, and Col. 12, I. 30-33, which states that "The development 
process ... will generally end in the application deployment stage. Deployment takes 
built applications and installs them in the appropriate environments .") 

Iyengar et al. ('627) teach that the application can be developed in conjunction 
with middleware options (See Col. 11,1. 26-59), but do not explicitly teach the steps of 
executing the application logic in response to a request from a client, processing the 
request, returning a response, or presenting the response to the client. 

Diec ('568) describes a method and system for distributing objects over a 
network, which passes information between a client and a server through an 
intermediary server where transformation of the information takes place (See Abstract, 
Figs. 1 and 3 and related text, and Background and Summary of the Invention). The 
method of Diec ('568) comprises: 



Application/Control Number: 09/873,830 Page 7 

Art Unit: 2122 

"executing the application logic from the execution platform in response to an 
external request sent by an external client device, the external request having one or 
more parameters" (See Background of the Invention, e.g. Col. 1 , 1. 20-26, which states 
that "The end user at the client [requests information] which launches the CGI 
application on the Web server ... The end user at the client supplies the requested 
information, as a search request , an order , a user id and password , or the like, and 
sends the data back to the CGI program." The CGI application is executed in response 
to a request for information from the client, obtains information from the client to pass to 
the application server, and then sends the information to the application server to 
execute the application logic on the client's request.) 

"processing the external request' (E.g., see Col. 1, 1. 29-38, which states "the 
CGI application translates the query or information ...The web server sends the query 
or information to the application server. The application server performs the requested 
task...") 

"returning one or more response objects after processing the external request' 
(E.g., see Fig. 3, and Col. 3, I. 23-27, which states "The web server translates or 
otherwise converts . . . and sends the responses to the application server. The 
application server returns objects to [the] web server.") 

"presenting the converted response objects to the external client device" (E.g., 
see Col. 1, 1. 38-42, which states "The CGI application ... sends the ... information back 
to the client.") 
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Iyengar et al. ('627) also suggest that the developed application may be 
packaged with middleware, including "HTML and Internet Server based middleware", 
but that the application does not require specific middleware to be tested (See Col. 11,1. 
33-59). Furthermore, Diec ('568) also teaches that the application running on the 
application server, that is, the application logic being executed based on the request 
from the client, "can be a database application or an e-commerce application or the like" 
(See Col. 1, I. 31-34). 

Therefore, one of ordinary skill in the pertinent art would have an understanding 
of the application development and deployment steps disclosed by Iyengar et al. ('627), 
the application execution steps disclosed by Diec ('568), and the implied connection 
between the two methods. It would have been obvious to one of ordinary skill in the 
pertinent art at the time of invention by applicant to combine the teachings of Iyengar et 
al. ('627) and Diec ('568) to create a method for developing, deploying, and executing 
application logic in response to a client. 

One of ordinary skill in the art would have been motivated to augment the 
development and deployment method of Iyengar et al. ('627) with the middleware 
execution method disclosed by Diec ('568) to support clients that cannot support object- 
oriented input and output structures. One of ordinary skill in the art would have been 
further motivated to combine the teachings of the references to produce a single, 
concise means for developing, deploying, and executing an application whose 
capabilities extend to network and Internet use. Such a means would be an all-in-one 
package, thus more user-friendly and straightforward than the use of independent 
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proprietary means in concert. Such a means would also make the developed 
application more accessible through network and Internet deployment. 

As to claim 2, Diec ('568) further describes a processing step where "The web 
server translates or otherwise converts the responses [from the client] into a suitable 
form for the application server (converting the parameters of the external request), and 
sends the responses to the application server (passing the converted parameters to the 
application logic). The application server returns objects to the web server" (e.g., see 
Fig. 3 and Col. 3, 1. 23-27). It is implied that a suitable format for the input to the 
application server is objects, since the application server outputs objects (converting ... 
to one or more objects). This teaching, combined with the teachings of the references 
as applied above to claim 1, reasonably reads on the limitations of applicant's claim 2. 
One of ordinary skill in the art would also have been motivated to combine these 
teachings for compatibility with object-oriented applications and databases, and to 
provide fuller advantages of such an all-in-one package means. 

As per claim 3; Diec ('568) further describes a system, stating that "This interface 
application program sends a markup language form ... to the client, and receives 
information ... from the client in response to the markup language form (parameters of 
the external request). This information is sent from the web server to the application 
server ... The interface receives responsive information from the application server ... 
[which] includes functions objects, data objects, and application objects (response 
objects) ... This information ... is converted into markup language (converting the 
response objects to a predetermined format based on a type of the external client 
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device or the parameters of the external request), and transmitted to the client" (e.g., 
see Col. 3, 1. 37-51). This teaching, combined with the teachings of the references as 
applied above to claim 1 , teaches the limitations of applicant's claim 3. One of ordinary 
skill in the art would also have been motivated to combine these teachings for 
compatibility with non-object-oriented clients, and to provide fuller advantages of such 
an all-in-one package means. 

In regard to claim 4, Iyengar et al. ('627) also describe a repository (storage 
device schema) in which "all of the entities and objects associated with the application 
under development, as well as relationships between these entities and objects, are 
stored {one or more storage device schemas in at least one storage device as required 
by the captured application logicf (e.g., see Col. 4, I. 21-32). It is inherent that the 
repository is generated during development of an application to store the developed 
components of that application. Since the repository is not a transient storage medium, 
it is also inherent that such a repository resides on at least one storage device. This 
teaching, when combined with the teachings of the references as applied above to claim 
1 , reads on the limitations of applicant's claim 4. 

With respect to claim 5, Iyengar et al. ('627) also state that during the application 
deployment stage, "Deployment takes built applications and installs them in the 
appropriate environments (saving the captured application logic to the execution 
platform)" (e.g. see Col. 12, I. 30-33). Inherent to installing an application is saving the 
components of that application for later execution. This teaching, combined with the 
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teachings of the references as applied to claim 1 , recites the limitations of applicant's 
claim 5. 

Referring to claim 6, Diec ('568) further describes the possible applications of the 
application server, "for example to read and write data to a database (retrieving one or 
more objects from . . . and updating one or more storage device schemas in the storage 
device)" (e.g. see Col. 3, 1. 65-66 and Col. 4, 1. 1-5). Reading from a database (storage 
device schema) causes the database to return information, and the application server 
described by Diec ('568) returns objects; thus, instructing the application server to read 
from a database would cause it to retrieve one or more objects from the storage device 
on which the database resides. Writing to a database adds to or updates the 
information stored in that database; thus, instructing the application server to write to a 
database would cause it to update that database. This teaching, combined with the 
teachings of the references as applied to claim 1 , recites the limitations of applicant's 
claim 6. One of ordinary skill in the art would also have been motivated to combine 
these teachings to allow the developed application to access databases, including 
object-oriented databases, and to provide fuller advantages of such an all-in-one 
package means. 

As to claim 7, Iyengar et al. ('627) also teach the implementation of a class 
diagram, which describes "the types of objects in a system and the various kinds of 
relationships which exist between them (defining one or more interrelated objects for the 
visual models)" (e.g. see Col. 3, 1. 65-66 and Col. 4, 1. 1-11). The reference also 
discloses a means for creating the methods that represent the details of business 
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processes (one or more high-level structure). "For example, if the business process is 
the handling of purchase orders, one detail ... may be that purchase orders over $1 ,000 
must be approved by a manager" (see Background of the Invention, e.g. Col. 1, 1. 34- 
41 ). This example represents a formula that details a part of the business logic (one or 
more formulas to represent the application logic). Iyengar et al. 0627) provide a means 
for the user to write and edit business logic, in the language of the user's choice, as part 
of the development phase (see Fig. 1 and related text, e.g. Col. 2 I. 57-58). These 
teachings, combined with the teachings of the references as applied to claim 1 , read on 
the limitations of applicant's claim 7. 

Claim 9 is an amalgamation of the limitations of claims 1 , 3, and 4, and one of 
the limitations of claim 2, "converting the parameters of the external request to one or 
more objects". The teachings of the combination of Iyengar et al ('627) and Diec ('568) 
address all of these limitations, as shown above. Thus, the teachings of the combined 
references read on all of the limitations of claim 9. 

Claim 10 recites the limitation of claim 2 that is not recited in claim 9, "passing 
the converted parameters to the application logic", and applies it with the limitations of 
claim 9. This has the net effect of applying all of the limitations of claims 1 , 2, 3, and 4 
in a single claim. However, since the combined references teach all of the limitations of 
claims 1 -4 as shown above, they also teach all of the limitations of claim 1 0. 

Claims 11, 12, and 13 recite the same limitations as claims 5, 6, and 7, 
respectively. Since the combined references teach all of the limitations of claims 5-7 as 
shown above, they also teach all of the limitations of claims 11-13. 
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Addressing claim 14, Iyengar et al. ('627) disclose a means for creating the 
methods that represent the details of business processes, and provide an example of a 
formula regarding the approval of purchase orders, as described above in reference to 
claim 7. This formula can be represented by a decision statement (a process). Since 
the example in the reference embodies a process, this teaching, when combined with 
the teachings of the references as applied to claim 9, reads on the limitation of 
applicant's claim 14. 

As to claim 15, Iyengar et al. ('627) discuss a means for creating the methods 
that represent the details of business propesses, and disclose an example of a formula 
regarding the approval of purchase orders, as described above in reference to claim 7. 
This formula can be represented by a decision statement, or a decision rule . Thus, in 
the example disclosed by the reference, the high-level structure can also be a rule. This 
teaching, combined with the teachings of the references as applied to claim 9 above, 
reads on the limitation of applicant's claim 1 5. 

Claim 17 is a system claim which recites the same limitations as those of the 
method of claim 1 . Although claim 1 7 is directed to a different class of statutory subject 
matter than claim 1 , it does not recite any limitations different than those of claim 1 . 
Therefore, as the combined references teach all of the limitations of claim 1 as shown 
above, they also teach all of the limitations of claim 17. 

Similarly, claims 18, 19, 20, 21 , and 22 are directed to a different class of 
statutory subject matter (a system rather than a method), but recite the same limitations 
as claims 2, 3, 4, 6, and 7, respectively. Since the combined references teach all of the 



Application/Control Number: 09/873,830 Page 14 

Art Unit: 2122 

limitations of claims 2-4 and 6-7 as shown above, they also teach all of the limitations of 
claims 18-22. 

11. Claims 8, 16, and 23 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Iyengar et al. ('627) in view of Diec ('568) as applied to claims 1 , 9, and 17 above, 
and further in view of Rational Rose. 

Referring to claim 8, Iyengar et al. ('627) teach the applications of relationships to 
objects in a class, including associations (relationship to at least one other object), 
subtypes {object type), and aggregations (object attribute). Since these descriptors are 
defined at the class level, they are defined for each. object (e.g. see Col. 4, 1. 3-1 1 ). 
Iyengar et al. ('627) also teaches the use of Rational Rose 4.0 as a tool to develop 
object models in accordance with the invention (see Fig. 8 and related text, e.g. Col. 9, 
I. 13-28). 

Iyengar et al. ('627) do not explicitly teach the step of defining the expected 
behavior of each object in a class. 

Rational Rose describes the assignment of many different parameters to classes, 
and to objects within those classes (see Using Rational Rose 4.0, Chapters 1-13 and 
Appendix A). The reference describes the section where a user writes the specification 
of a class or object, enabling the user to "display and modify the properties (attributes) 
and relationships of a model element, such as a class (object type), a relationship , or an 
operation (expected behavior) 71 (e.g., see Pg. 31 , par. 7). Rational Rose further defines 
the role of the Operations tab in a class specification, stating that operations "can be 
methods ... that implement characteristic behaviors (expected behavior) of a class" (see 
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Chapter 4, related figures and text, e.g. Pg. 49, par. 1 ). Since classes describe their 
objects, defining the specification of a class inherently defines the default properties and 
relationships of each object in that class {defining further includes, for each object, ...)• 

Therefore, it would have been obvious to one of ordinary skill in the pertinent art 
at the time of invention by applicant that defining the expected behavior of an object 
would also be included in the invention of Iyengar et al. ('627), using the teachings of 
Rational Rose. One of ordinary skill in the art would have been motivated to use this 
teaching to take full advantage of the existing functionality of the prior art. 

Claim 16 recites the same limitations as claim 8. Since the combined references 
read on the limitations of claim 8 as shown above, they also read on the limitations of 
claim 16. 

Claim 23 is directed to a different class of statutory subject matter than claim 8, 
but recites the same limitations as claim 8. Since the combined references teach the 
limitations of claim 8 as shown above, they also teach the limitations of claim 23. 

Conclusion 

12. The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure. 

1 3. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Matthew A. Dickeson whose telephone number is (571) 
272-7219. The examiner can normally be reached on Monday thru Friday, 8:00am - 
4:00pm. 
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If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Tuan Q. Dam can be reached on (571) 272-3695. The fax phone number 
for the organization where this application or proceeding is assigned is 703-872-9306. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 
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